Assessment and analysis of software security flaws

ABSTRACT

Security analysis and vulnerability testing results are “packaged” or “bound to” the actual software it describes. By linking the results to the software itself, downstream users of the software can access information about the software, make informed decisions about implementation of the software, and analyze the security risk across an entire system by accessing all (or most) of the reports associated with the executables running on the system and summarizing the risks identified in the reports.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of and claims priority to andthe benefits of U.S. patent application Ser. No. 12/819,627, filed onJun. 21, 2010, now abandoned which is a continuation in part of andclaims priority to U.S. patent application Ser. No. 12/031,918, filed onFeb. 15, 2008, now U.S. Pat. No. 8,499,353 which claims priority to andthe benefits of U.S. provisional patent application Ser. No. 60/901,874,filed on Feb. 16, 2007. This application also claims priority to and thebenefit of U.S. provisional patent application Ser. No. 61/243,735,filed on Sep. 18, 2009.

FIELD OF THE INVENTION

The invention relates generally to the identification and reporting offlaws in software programs.

BACKGROUND

In recent years, many companies and government agencies have beenexposed to negative press and legal proceedings due to high-profilesecurity breaches in which sensitive data has been either inadvertentlydisclosed or stolen. While many of these incidents were the result ofhuman error, a significant percentage was traced back to poorly designedsoftware architecture and/or applications. Conventional techniques fortesting software applications can identify many vulnerabilities, but noone methodology is failsafe. Furthermore, although manysecurity-analysis techniques require significant time and resources toadminister, not every application necessitates the same level or degreeof analysis.

As a result, companies face a difficult trade-off between the desire totest software and limitations on available resources and time. Moreover,many companies do not have the expertise to apply some of the moreintricate and complex security assessment techniques, and thus look toindustry experts for such services. This creates yet another challenge,in that often what is being tested is highly sensitive, proprietarysoftware.

There are a myriad of testing and assessment techniques for validatingvarious properties of software applications and network implementations.However, one of the most critical processes for ensuring that thedeployment of software does not expose an organization to unacceptablerisks is security and vulnerability testing. Some of the conventionaltechniques used to perform such testing includes static analysis(automated code review), dynamic analysis (automated penetrationtesting) and manual analyses such as code review, design review, andmanual penetration testing. All of these analysis techniques are aimedat finding security weaknesses and vulnerabilities in an application andtypically provided in report format to the programmers, product managersand quality assurance (QA) staff. The report can provide detailedresults (e.g., program names, line numbers, variable names, dataconnections, etc.) as well as a summary of the results. The report maybe a conventional document such as a text file or a structured XML file.

However, once the report is run and reviewed by a QA engineer or productmanager, it is typically no longer referenced or used. Furthermore, asan executable or application is implemented and/or provided to acustomer, the report is forever decoupled from the software that wastested. In fact, an individual or organization using software has noknowledge that a report was ever created or used to analyze the softwarethey are now using.

As such, valuable information about what aspects of the application weretested, how secure certain features or functions may be and what testingmethodologies were used are unknown to those that value suchinformation. What is needed, therefore, is a system and associatedtechniques that can not only produce vulnerability and security testreports using various testing methodologies, but can create and maintainlinks between the application and its test results as the applicationsare deployed and throughout their lifecycle.

SUMMARY OF THE INVENTION

In general, the present invention facilitates security assessment andvulnerability testing of software applications in a manner responsive tothe technical characteristics and the business context in which theapplication operates (collectively, “application metadata”). Theinvention may, for example, determine an appropriate assurance level andtest plan to attain it. In many instances, a test plan may dictateperformance of different types of analyses. In such cases, theindividual tasks of each test are combined into a “custom” or“application-specific” workflow, and the results of each test may becorrelated with other results to identify a wide range of potentialvulnerabilities and/or faults that are detected by the different tests.As such, a programmer reviewing the results can better understand howdifferent potential vulnerabilities may relate to each other or in factbe caused by a common flaw.

Furthermore, once an application is deployed, the universe of threatsthat may impact the application continues to expand, and therefore theplatform preferably provides the infrastructure and methods forcontinuous, periodic or event-triggered application assessments, even asthe application operates in a secure production environment. Applicationusers and/or owners may also simultaneously view both the application“infrastructure” (e.g., source code, architectural components, objectcode abstractions, user case diagrams, UML diagrams, and/or websitemaps) as it exists in their operational environments and the results ofthe periodic security assessments, which can remain stored within theanalysis platform. For example, in one implementation, the analysisplatform runs on a server accessible to the application user via theInternet. The server periodically uploads (or otherwise accesses) theapplication, performs a security analysis, and alerts the user to theresults. Application owners and/or users may access the results of thisand previous assessments, which are stored on (or retrievable by) theserver.

Accumulating both application-specific metadata and security analysisand assessment results for numerous applications from many companiesfacilitates benchmarking of applications against other applications atmany levels within an organization. Use of various “anonymizing” and“scrubbing” techniques (i.e., removing any information that could bedeemed proprietary and/or identify an application's user or owner)permits the sharing of assessment data among otherwise unrelatedentities. Benchmarking may take place on a global scale (i.e., acrossall applications being monitored), within particular subsets ofapplications (e.g., those from a specific industry and/or working with aspecific technology), or based on personnel (e.g., for a particulardeveloper, team, organization or company).

Therefore, in a first aspect, a computer-implemented method forproviding access to security data related to a software applicationincludes creating a programmatic association between results of securityanalysis tests performed against a software application and the softwareapplication and storing the results for subsequent electronic access.Further, instructions to access the results are provided such that usersof the software application may review the results on demand.

The software application may include object code distributed over anetwork, in which case the results may be distributed with theexecutable object code. In other cases, the software application may bean application package, and the results are included in the applicationpackage. The software application may also be a web-based serviceaccessible over a network and/or a collection of unrelated computingfunctions available over the Internet. The results may be stored in acentralized database, access to which may be limited based on userauthentication credentials. In certain cases, the database storesresults from multiple software applications such that the results foreach software application are individually accessible based on a uniquekey. The results may be displayed and/or transmitted to the user over anetwork (encrypted, in some cases), and done so in response to a querysubmitted to the database. In some implementations, a hash function isused against at least a portion of the software application. Thecomputed hash may then be included with the distributed application,and, upon receiving a request from the user to view the results thatincludes the hash, the hash may be used to identify and access theresults. In some cases the instructions to access the report comprise aURL directing the user to the report, which may be formatted as an XMLdocument having predefined tags.

In another aspect, a system for providing access to security datarelated to a software applications includes testing engines forperforming a plurality of vulnerability tests on the softwareapplications and associating results of the tests with the respectiveapplication. The system also includes a database for storing the resultsand a communications server for receiving a request from a user of oneof the software applications to access the results associated with theapplication, and, based on the received request, provide (and in somecases display and/or transmit) the results associated with theapplication to the user.

The software application may be executable object code and distributedover a network, and in some cases an application package such that theresults may included in the application package. In other instances thesoftware application may be a web-based service accessible over anetwork and/or a collection of unrelated computing functions availableover the Internet. The results associated with each software applicationmay be individually accessible based on a unique key. For example, thetesting engine may compute a hash of at least a portion of the softwareapplication, and the communication server then includes the hash withthe distributed application. Upon receiving a request from the user toview the results that includes the hash, the communications server anddatabase use the hash to identify and access the results.

Other aspects and advantages of the invention will become apparent fromthe following drawings, detailed description, and claims, all of whichillustrate the principles of the invention, by way of example only.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to the sameparts throughout the different views. Also, the drawings are notnecessarily to scale, emphasis instead generally being placed uponillustrating the principles of the invention

FIG. 1 is a block diagram of a software assessment and testing domainaccording to an embodiment of the invention.

FIG. 2 is a more detailed diagram of a software analysis engineaccording to an embodiment of the invention.

FIG. 3 is a flow chart depicting steps performed in developing asoftware analysis and testing workflow according to an embodiment of theinvention.

FIG. 4 is a flow chart depicting steps performed in developing asoftware analysis and test report according to an embodiment of theinvention.

FIG. 5 is a flow chart depicting steps performed in defining and loadinga software application for analysis and testing according to anembodiment of the invention.

FIG. 6 is a flow chart depicting steps performed in performing periodicsoftware application analysis and testing according to an embodiment ofthe invention.

FIG. 7 is a flow chart depicting steps performed in identifying andpresenting flaws in software applications.

FIG. 8 is a flow chart depicting steps performed in accumulating resultsfrom multiple software application analyses and tests according to anembodiment of the invention.

FIG. 9 is a flow chart depicting steps performed in providing softwareanalysis and testing benchmarks according to an embodiment of theinvention.

FIG. 10 is a flow chart depicting steps performed in securely submittingsoftware applications for analysis and testing according to anembodiment of the invention.

FIG. 11 is a flow chart depicting steps performed in securely viewingsoftware application analysis and testing results according to anembodiment of the invention.

DETAILED DESCRIPTION Architecture and Approach

The techniques and supporting systems described herein provide acomprehensive and customizable approach to detecting security flaws insoftware applications, recommending remedial courses of action, andreporting and benchmarking against, for example, industry-widestatistics, other developers and/or other development teams from withinor outside of an organization. Software applications may include (butare not necessarily limited to) any sort of instructions for a machine,including, for example, without limitation, a component, a class, alibrary, an script, an applet, a logic table, a data block, or anycombination or collection of one or more of any one or more of these. Anappropriate level, type and frequency of security analysis needed for asoftware application may depend on many factors, including (but notnecessarily limited to) the technical details of an application (e.g.,the language in which it is written and the platform on which is to bedeployed) as well as the business context in which the applicationoperates. For example, an application that is “customer-facing” andfacilitates high-volume, secure transactions such as banking orecommerce will require rigorous testing to ensure that customer data isnot jeopardized. Conversely, applications such as document-controlsystems or desktop applications that are implemented entirely within anorganization and operated behind secure firewalls require less stringenttesting. Therefore, balancing the added costs for executing additionalsecurity assessments and testing with the risks of potential for lossesis critical

FIG. 1 illustrates, in a broad overview, a representative securityassessment platform 105 for implementing the techniques describedherein. The platform 105 receives and reports on software applications110 from multiple entities, while monitoring numerous sources 115 ofexternal threats for up-to-date libraries of malware and application andenvironmental vulnerabilities. The platform 105 includes acommunications server 120 and an analysis engine 125. The communicationsserver 120 provides the conduit through which the platform interactswith external systems. For example, the communications server 120 mayutilize conventional data-communications protocols such as TCP/IP, HTTPand others to query application servers for updated applicationprograms, download updated programs, post analysis results, and send andreceive messages from users. More specifically, in a server-basedimplementation, the communications server 120 may act as an interfacebetween the platform 105 and external entities that submit softwareapplications for assessment or review assessment results. In addition,the communications server 120 may act as a conduit through which otherexternal data such as updated threat information (in the form of malwaredefinition files, for example) are received for storage in the securitythreat database 150. In some implementations, the security assessmentplatform 105 may be configured as a distributed platform, in which oneor more components (e.g., testing modules, threat-assessment agents,secure communication devices, databases, etc.) are duplicated and/ordistributed among multiple computers located remotely from each otherbut, for example, co-located with users of the platform. Examples ofcommunications server application platforms providing such featuresinclude the Apache HTTP Web Server supplied by the Apache SoftwareFoundation and the WebSphere HTTP Server supplied by IBM Corporation.

The analysis engine 125 receives application code and programs fromusers, either via the entity operating the platform 105 or directly fromcustomers using the platform 105 as a subscription service. The analysisengine 125 interacts with various testing engines and code reviewmodules, as well with assessment and threat databases, and includesbenchmarking and reporting capabilities for comparing assessment resultsamong applications, developers, teams and/or organizations. In oneembodiment, for example, the analysis engine 125 interacts with adynamic testing engine 130, a static testing engine 135, a pen testingengine 140 and a module for performing manual code review 145.

More specifically, the dynamic analysis engine 130 interacts with theapplication 110 as an external entity and executes the application 110in a manner that mirrors or emulates the runtime environment in which itoperates. In some embodiments, the dynamic analysis engine 130 receivesa description of the interfaces to the application 110, sends testand/or simulation data to the application via the interfaces, andanalyzes the received responses. The test data may beapplication-specific (e.g., provided with the application as a library,data file, or structured input) or application-agnostic, such as dataand/or scripts known to exploit application vulnerabilities. Based onthe responses, the dynamic analysis engine 130 determines whether anysecurity defects exist in the application 110 and the extent to which itmay be vulnerable to certain threats. The defects may be reported inreal-time (e.g., via the communications server 120) and/or stored in adatabase for subsequent analysis and reporting.

The static analysis engine 135 receives a binary or bytecode version ofthe application 110 as input. For example, a high-level semantic modelof the application 110 is created containing control-flow and data-flowgraphs of the application 110, and this model then analyzed for qualitydefects, including security flaws, by a set of analysis scans.

The pen testing engine 140 performs penetration testing of theapplication 110. Penetration testing includes, for example, simulatingand analyzing various web-based interactions between a client and theserver on which the application 110 operates. This includes executingstandard HTTP commands such as GET and POST, analyzing FORM elements andscripting elements (both client and server-side), and manipulatinginputs to elicit known vulnerabilities.

The analysis engine 125 may also receive input from manual reviewprocesses executed using a manual code review module 145. Manual reviewprocesses typically include a human operator visually reviewing sourcecode to determine if proper coding form and standards have beenfollowed, and looking for “extra” functions often left in applicationssuch as trap doors, easter eggs, and similar undocumented functionality.

For web-based applications, a dynamic web scan may be used to “crawl”through the application by manually navigating the web site to betested. In this manner, a person or automated “bot” interacts with all(or some selected subset) of the user interface elements and entersvalid data. In some cases, pre-defined invalid data (either in format orsubstance) may be included to test the application's response. In somecases, an automated testing process such as a regression test harnessmay also be used. During the crawl, a browser plug-in or a proxy runningon the client records all web requests to and responses from the webapplication. After the crawl has successfully navigated the webapplication, the recording process is stopped. The recorded requests andresponses may be uploaded to the analysis engine 125. In some instancesthe crawl may be performed by the entity operating the platform 105,whereas in other instances the crawl may be performed by the owner ofthe application being tested, and the resulting data and applicationloaded into the platform together.

The data, scripts and functions used to operate the various testingengines and the analysis engine 125 may be stored in a security-threatdatabase 150. The database 150 may be operated as a stand-alone serveror as part of the same physical server on which the analysis engine 125operates. Portions of the threat database 150 may, in some cases, beprovided by entities other than the entity operating the platform 105 ona subscription basis, allowing the database 150 to be kept up to date asthreats and malware evolve over time. Likewise, the results of each testand the overall analysis process may be stored in an assessment-resultsdatabase 155. In some embodiments, the applications and analysis resultsare stored in an encrypted format using a unique key provided to theowner of the analyzed application 110 such that only it can access andreview the results of the analysis. In such cases, decryption of theanalysis is limited to authorized personnel and all traces of theanalysis are deleted from memory (other than the database 155) followingcompletion.

Examples of database applications that may provide the necessaryfeatures and services include the MySQL Database Server by SunMicrosystems, the PostgreSQL Database Server by the PostgreSQL GlobalDevelopment Group of Berkeley, Calif., or the ORACLE Database Serveroffered by ORACLE Corp. of Redwood Shores, Calif.

FIG. 2 illustrates, in greater detail, the analysis engine 125 and itsvarious components. In one embodiment, the analysis engine 125 includesan assurance recommendation engine 205, a workflow constructor 210, astimulus analysis evaluation engine 215 and a workflow engine 220. Eachof these components (described in greater detail below) interacts withthe various testing engines 130-145 and executes various processes inaccordance with an application-specific testing workflow, which isdefined by an assessment correlation engine 225. Results from theanalysis and testing are provided to a grading and reporting engine 230,which includes a benchmark engine 235, an anonymizer 240 and a flawviewer 245. In some embodiments, such as those where the analysis andtesting services are provided remotely and/or via a web-basedsubscription service requiring transmission of application componentsand results over public networks (i.e., the Internet), a digital rightsmanagement packager 250 and engine 255 may be used to encrypt theapplication and analysis results.

More specifically, the assurance recommendation engine 205 receivesapplications and application metadata and automatically determinesvarious characteristics of the application. For example, therecommendation engine 205 may recognize the programming language used towrite the application 110, specific libraries used within theapplication, the development environment used to build the application,application programming interfaces (APIs) available to users, the sizeof the application, as well as other technical qualities. Moreover, theentity responsible for submitting the application (which may be theowner of the application, a licensee, or an end user) may provideadditional business context information such as the requiredavailability (e.g., 99.99% uptime), expected throughputs or transactionvolumes, types of users who will operate the application, whether theapplication will be exposed to the public, the operating system in whichthe application executes, other applications with which the applicationinteracts, and others.

The metadata is supplied by the entity operating the platform, the ownerof the application, or, in some cases, may be provided by a third party.In such cases, the metadata may include information related to thespecific application, a group of applications (e.g., all bankingapplications within a retail bank), an enterprise-wide collection ofapplications, or, in some cases, industry-wide data.

The recommendation engine 205 considers these technical and businesscharacteristics and application metadata and determines a recommendedassurance level. As described in more detail below, the assurance levelsare used by the workflow constructor 210 to define an assessmentworkflow based on various testing techniques such as dynamic applicationtesting, static binary testing, automated and manual pen testing, aswell as manual code review.

Once a workflow has been established by the workflow constructor 210, aworkflow engine 220 submits the application to the various testingengines. The results of these tests may include such items as errorrates, specific occurrences of errors, compliance with industrystandards, as well as other data. The assessment correlation engine 225correlates the different test results received from the testing engines130-145 and organizes them by application module and type of error,identifies duplicates, and recognizes correlations among differenterrors.

The analysis engine also may include a grading and reporting module 230that includes a benchmark module 235, an anonymizer 240 and a flawviewer 245. The benchmark module 235 compares the testing and analysisresults for one or more applications having similar application profilesand/or metadata. This allows the application's owner to see how theapplication's architecture and security features measures up againstother similar applications.

In some instances, the benchmark engine 235 calculates and compares testresults at a more granular level. For example, an organization may wishto determine which of its developers (or development teams) produces thebest code, the most secure applications, or is most prone to developmenterrors. By including information such as the code author, developmentgroup, and/or other organizational information, the platform may be usedwithin a company to identify core strengths and/or key weaknesses.

The anonymizer 240 removes company-specific information from the resultsand/or aggregates the results such that they may be provided tosubscribers or the public in general. In this manner, the platform 105provides global view of software development and implementation trendsrelated to security and vulnerability testing across a wide spectrum ofindustries and technologies.

As an example, a bank may be developing a new customer serviceapplication that allows its clients to execute transactions via the Web.Based on the technology used to develop the application (e.g., ActiveServer Pages, java, PHP), the fact that the application is available tothe general public, and the information transmitted is highly sensitive(account numbers, PINs, etc.), the assurance recommendation engine 205may determine that this application be tested as fully as possible. Eachtesting engine will then process the application (either remotely or asreceived at the platform 105) and the results are correlated into acomprehensive assessment report. Once completed, project managers at thebank may log into the platform using secure IDs and passwords, biometricauthentication, PKI techniques or other such methods and, using the flawviewer 245, review and comment on any vulnerabilities identified duringtesting. On some cases, the project managers may also see how theapplication fared against similar applications submitted by other banks.

In some embodiments, the vulnerability and quality scans are performedduring the development of an application, and as such the results may beshared with the development team in real-time. This allows programmersand project managers to be apprised of potential flaws in their codeprior to system testing or deployment, greatly reducing the time andcost to implement large-scale systems. In some cases, ongoing trendsderived from industry-wide statistics (e.g., a bank's peer group isshifting to a newer, more secure java framework, or has migrated fromMySQL to Oracle) are provided to help guide developers' efforts. Inother instances, the prevalence of certain code across an enterprise orindustry (e.g., commonly-used open source components, for example) istracked over time and periodic updates may be sent to developers know tobe using the code if newly discovered issues (technical, legal or both)are identified.

Regardless of the implementation, the method of implementing anddistributing the various components of the platform is arbitrary. Forexample, in some implementations all components of the platform may becompletely contained within an organization (e.g., within a firewall,accessible via a VPN or intranet) and available as an “on-demand”service as part of an overall development methodology. In otherembodiments, the platform may be implemented as a web-based serviceavailable to numerous organizations that “subscribe” to the platform andare therefore able to subject their software applications to structuredsecurity assessment testing on an as-needed basis. Furthermore, various“anonymizing” or aggregation techniques can be used to remove orotherwise protect proprietary information and/or data that wouldidentify the application owner. Assessment results from numerousapplications across industries, technical platforms, application sizes,etc. can be extracted to provide cross-entity benchmarking data toplatform subscribers. In addition, analysis of the assessment resultsand subsequent monitoring of the applications (for undetected securityflaws or unexpected operational reactions to certain threats, forexample) allow the platform 105, and specifically the workflow engine220, to be refined and improved. By operating the platform 105 as acentralized yet secure resource for multiple entities, assessment datacan be used for historical and industry benchmarking, as well as toupgrade the techniques used to determine assurance levels and builtappropriate workflows.

In such cases, the need to securely transmit application code (bothbinary and source) to and from the platform 105 is crucial. One methodfor implementing the needed security measures is via digital rightsmanagement (DRM). In general, DRM refers to various access controltechnologies used by publishers and copyright holders to limit access toand/or usage of digital media or devices. Just as DRM is used to protectconventional copyrighted material (e.g., audio and video content), itmay also be employed to protect source and binary code of an applicationas well the analysis and testing results generated by the platform 105.More specifically, a DRM packager 250 may be used to encrypt some or allof the application information and produce a key to decrypt theinformation. A DRM engine 255 executes the encryption and decryptionfunctions that allow users to securely view application data via aremote device. Further operational and functional characteristics of DRMmodules 250, 255 are set forth below.

Assessment and Recommendation

Referring now to FIG. 3, one embodiment of the assessment andrecommendation techniques of the invention includes three phases—adata-collection phase, an assurance-level determination phase, and aworkflow-build phase. More specifically, the data-collection phaseincludes collecting technical details (STEP 305) about the applicationsuch as the platform on which it will be built and/or implemented, thenetwork topology over which it will operate, the language or languagesused to develop the application, third-party applications or modules theapplication will interact with or use, the security environment in whichthe application will operate, as well as other applicationcharacteristics. In addition, the business context in which theapplication will operate is determined (STEP 310), and combined with thetechnical details to produce an application profile P. In onenon-limiting example, some or all of the business factors identified inthe Federal Information Processing Standard (FIPS) (i.e., damage toreputation, financial loss or business liability, harm to businessinterests, unauthorized release of sensitive information, personalsafety, civil liability and potential criminal violations) can be usedas guidelines for measuring the security risks in light of the businesscontext of the application. Each of the FIPS factors can be assigned arating (e.g., as n/a, minimal, moderate or serious), and in someembodiments certain factors are weighted more than others according torelative importance, (e.g., as defined by a user or industry standards).For example, an application that processes healthcare data includingpersonally identifiable information may accord a rating of “serious” tofactors such as damage to reputation, liability, unauthorized release ofsensitive information and criminal liability, but “n/a” for personalsafety. In instances in which this analysis has previously been done andan assurance level already determined, that assurance level can beimported (STEP 315), and in some circumstances updated if necessary.

If an assurance level was provided with the application as part of thedata collection phase (DECISION STEP 320), the analysis workflow can bebuilt. Otherwise, the assurance recommendation engine reviews theapplication profile P and determines an appropriate assurance level(STEP 325). One approach for determining an appropriate assessment levelis to consider the ratings assigned to each of the business contextfactors, and select an appropriate assurance level based on the highestrating. For example, if any of damage to reputation, financial loss,harm to business interests, release of sensitive information or civil orcriminal violations are rated “serious,” the highest assessment level isrecommended. If, however, all factors are either minimal or n/a exceptfor, e.g., the “civil violations” factor (which is assigned a “moderate”rating), a lower but still relatively high assurance level is specified.Table 1 below summarizes one possible mapping of business impact factorsand their ratings to recommended assessment levels.

TABLE 1 Assurance Level Profiles Assurance Level Impact ProfilesPotential Business Impact Categories for Application Flaws AL2 AL3 AL4AL5 1. Inconvenience, distress or damage to Min Mod Mod Serious standingor reputation 2. Financial loss or business liability Min Mod ModSerious 3. Harm to business interests N/A Min Mod Serious 4.Unauthorized release of sensitive N/A Min Mod Serious information 5.Personal Safety N/A N/A Min Mod 6. Civil or criminal violations N/A MinMod Serious

The recommended assurance level (and in some cases options to modify thelevel) can then be presented to the user (STEP 330), who selects theassurance level (STEP 335) for the particular application.

In the workflow build phase, varying combinations of analysis techniquescan be used to adapt a security review workflow to the particulartechnical and business criteria of an application, with one key goalbeing the reduction of false negatives, i.e., undetected security flaws.Different types of analysis (e.g., automated, manual, static, dynamic,etc.) have different false negative rates because they are either unableto detect particular security defects (100% false negative rate) or theyhave varying levels of false negatives depending on the threat. As aresult, introducing additional security analysis processes into theworkflow lowers the false negative rate. But multiple analysistechniques require the expenditure of more time and resources, and soshould be integrated into the workflow when they contribute meaningfullyto the overall reliability of the analysis or to lower the falsenegative rate below a predetermined threshold.

In one implementation, the workflow W is constructed (STEP 340) byselecting different analysis techniques from the following table. Thehigher the desired assurance level, the more analysis techniques arerecommended. The analysis techniques are arranged according to the timeand resources estimated to perform the analysis, thereby minimizingcosts and only introducing more stringent analyses when the impact of asecurity event is greater. Once the workflow is determined and approvedby the user, the various analysis techniques are performed. Table 2below illustrates how various analysis techniques may be used againstapplications with different assurance levels.

TABLE 2 Analysis/Assurance Level Mapping Analysis Assurance LevelsTechniques AL1 AL2 AL3 AL4 AL5 Automated None • • • • Static AnalysisRequired Automated • • • Dynamic Analysis Manual • • Dynamic AnalysisManual Code • ReviewChaining and Correlation of Analysis Results

Combining multiple types of application analysis generally produces abroader application vulnerability profile. For example, combining binarystatic analysis and dynamic analysis techniques provides increasedaccuracy and more informative analysis results because the outcome of abinary static analysis can be used as input into a secondary dynamicanalysis. The dynamic analysis process itself produces two results: adynamic assessment and a static coverage map. The static coverage mapcontains each dynamic path used to reach a flaw detected during thestatic analysis.

The static results, dynamic results, and static coverage map are used toproduce a report of static flaws not pathed (lowest priority), staticflaws with a dynamic path (high priority), and dynamic flaws not relatedto the portions of the application that have been statically analyzed(e.g., environment/configuration). The data flow and control flow graphsgenerated by static analysis may also be used to compute a dynamic testcase for each identified flaw. In such cases, input data and an inputvector may be generated that will recreate and retest each flawdynamically to determine if the flaws have been addressed. Morespecifically, and with reference to FIG. 4, the following steps can beperformed to combine results from both the static and dynamic testing:

-   -   STEP 405: Run the binary static analysis, recording the binary        offset of a potential defect within the tested executable. The        results R may be stored and/or used as input into the pen and        dynamic testing.    -   STEP 410: Instrument the binary within a runtime test        environment in preparation for the dynamic test. A correlation        agent is executed on the same computer as the binary will        execute. The correlation agent loads the binary and sets debug        breakpoints or shims at each binary offset at which potential        defect was detected during the binary static analysis. The        results R′ may be stored and/or used as input into the dynamic        analysis.    -   STEP 415: Run the dynamic analysis. The dynamic analysis uses        general test cases to find new flaws and specific test cases to        retest flaws identified during the static analysis. During the        analysis, the dynamic tester listens for call backs from the        correlation agent running on the computer under test. If it        receives a call back it records the time and information sent by        the agent. During the dynamic test, if a debug breakpoint or        shim is hit, the correlation agent sends a callback to the        dynamic tester with information about the breakpoint or shim        offset within the executable.    -   STEP 420: Determine, using a correlation process, which dynamic        test inputs correlate to which potential defects found during        binary static analysis by using the callback information.    -   STEP 425: Create a summary S from the correlated results U. If        defects were found by both static and dynamic analysis then        those defects are reported as high confidence.        Continuous Application Assurance

In some embodiments, continuous application assurance provides forautomatic re-analysis of an application. Re-analysis is triggered bychanges in the external application environment (e.g., threat space,business intelligence, detected attacks) and/or the implementation ofenhanced analysis capabilities (e.g., a new scan has been added to ananalysis workflow to detect new class of vulnerability). An intelligentre-analysis decision can be made by taking into account factors such asapplication profile, previous vulnerability assessment results, and thetype of change (e.g., threat and/or scan capability).

A decision to initiate a re-analysis can be based, for example, on anapplication's technological profile, metadata describing theapplication's functionality, the deployment environment of theapplication, new information about vulnerabilities that may affect theapplication, and/or increases in a likelihood of a threat. External datafeeds and internal scan capabilities database are used to triggerrescans of the application. For example, suppose a new vulnerability isdiscovered in how data is transmitted and processed using XML and WebServices that did not exist when the application was first scanned. Allapplications having metadata that includes both XML and Web Services areidentified, and the relevant analysis workflows are updated with the newscan information and re-processed.

In one embodiment, with reference to FIG. 5, the initial steps for anapplication-specific or customer-driven rescan include:

-   -   STEP 505: Define an application profile P for a web-based        application, e.g., a J2EE-based retail brokerage application for        a Fortune 100 financial services company, deployed with an        Apache web front-end and backed by an Apache Tomcat application        server and an Oracle database. In addition to the web interface        aimed at consumers, the application has a Web Services API for        exchanging data and enabling partners to conduct transactions.    -   STEP 510: Define rescan conditions based on the application's        attack profile. In this example, any new attack vectors against        Java applications or XML (for the Web Services interface) as        well as attacks specifically targeting infrastructure        components—Apache, Tomcat, and Oracle would constitute a rescan        condition.    -   STEP 515: Upload the application A to the platform and perform        the initial binary analysis to model the application's data        flows and control flows.

In some implementations, the rescanning process may be implemented as arequired step for submitting code or applications to a third-partyapplication platform. For example, an entity that provides a suite ofcommunity-developed applications for its communications andentertainment devices (e.g., the AppStore by Apple) may, as a conditionfor offering an application, require the application be scanned prior tobeing made available to the public. The scan may be done prior to aninitial upload, as well as on a periodic basis. In some instances, thescan may not be required, but a recognizable label (e.g., an icon, orimage) is shown alongside the application to indicate that it has beenscanned for potential vulnerabilities. In other cases, a user may beoffered the application for free, but, if they want the additionalassurance of having the application scanned, may pay a nominal fee(e.g., $2.99).

In addition to single application rescans as described above, aplatform-wide rescan may also be initiated in which multipleapplications (possibly owned and/or operated by unrelated entities) arerescanned. In addition, application owners may “subscribe” to a periodicand/or event driven rescan service that continuously determines ifrescans are necessary and if so, performs the appropriate analysis. Morespecifically, and referring to FIG. 6, one method for implementing aglobal rescan includes the following steps:

-   -   STEP 605: A new method for attacking XML interfaces is        discovered and threat metadata M and general remediation        information T are imported into the threat database.    -   STEP 610: When a new attack vector is discovered, security        researchers and developers create a new scan that detects        instances of the vector. The new scan capability is classified,        codified, and is added to the threat database 150.    -   STEP 615: Generate and store a re-scan change event in the        database.    -   STEP 620: Determine which applications are identified for        continuous application assurance, and perform the following        steps for each such application.    -   STEP 625: The stimulus analysis evaluation engine 215 uses the        application profile P and the external analysis stimulus 115 to        determine whether or not the application needs to be        re-analyzed. For example, in the case of the XML interface        threat noted above, web applications that expose an XML-based        Web Services API are rescanned.    -   DECISION STEP 630: If the application is to be rescanned, move        to Step 635, otherwise check to determine if additional        applications are queued for rescan.    -   STEP 635: Build the analysis workflow W by comparing the        external stimulus to the application profile. In some cases, it        may not be necessary to re-run all of the existing scans, and        instead only run the new scans that apply to the particular        application.    -   STEP 640: Insert the application into the job queue Q along with        its custom analysis workflow W.    -   STEP 645: Repeat the process for each application configured for        continuous application assurance. For each application, either        it is deemed not in need of a re-scan, or it is added to the job        queue along with the corresponding workflow.        Remote Application Analysis

In some embodiments in which a static binary analysis is performedremotely (e.g., within the security assessment platform separate fromthe operational environment in which the application is implemented orwhere its source code is stored), the results of the binary analysis canbe linked to the original application source. These results aretypically stored and managed securely on within the platform 105, butcan be viewed by a remote user together with local application sourcecode using a viewer application.

Referring to FIG. 7, one method for providing simultaneous viewing ofidentified application flaws along with the application source code thatcaused the flaws can include the following steps:

-   -   STEP 705: Upload application metadata and application binaries A        from a local system to the assessment platform for analysis.    -   STEP 710: Initiate static binary analysis for the application        and store the results at the central location. As part of the        analysis, application flaws identified in the analysis results R        include references to application source code file and line        number obtained using debug symbol information during the        analysis.    -   STEP 715: An application user or owner logs into the platform        using a remote application and views the list of flaws stored in        the platform.    -   STEP 720: The user selects one or more individual flaws to view,        and in response a viewer program 245 in the remote application        locates and opens the associated local source code file A and        navigates to the relevant line number.    -   STEP 725: The process iterates though all flaws or, in some        cases, only those flaws identified as critical by the user.        Peer Benchmarking

In some embodiments, the platform 105 provides a common repository forapplication metadata as well as assessment results for numerousapplications across a variety of technical and business implementationsand/or of known quality. By maintaining such a database, the platformcan provide cross-application reporting that compares a particularapplication (or family of applications) to others in the same industry,to applications that use the same technology, and/or based on othercriteria rendering one class of application relevant to another. In someinstances, assessment results may be compared to those generated by atemplate application to determine the quality of the application ascompared to an application of known quality. Such reporting (referred toas “peer benchmarking”) allows an organization to gauge theeffectiveness of its own security initiatives relative to othercompanies in the same industry. Because the assessment platform providesconsistent and repeatable security-analysis techniques, a commonassessment vocabulary and a large sample size, the information providedto users has a greater global relevance than individual applicationassessment data.

Referring to FIG. 8, one method for providing peer benchmarkingreporting to users of the platform includes the following steps:

-   -   STEP 805: The application profile P is specified based on the        type of application and the business context. One example is a        customer-facing financial services web application written in        java.    -   STEP 710: The application is analyzed using a consistent,        repeatable process as described above.    -   STEP 815: A standardized analysis summary S is generated by the        reporting engine 230 that contains an overall security score and        other security metrics.    -   STEP 820: The analysis summary is anonymized so that the summary        cannot be traced back to the original application, the        organization that created the application, or the organization        that submitted the application for analysis. The anonymous        summary Y may be loaded into the assessment results database.

Once the results database 155 is populated with assessment results froma sufficient number of applications, users can specify and view variousreports. Some reports, for example, can indicate how, statistically, anapplication compares to its “peers” by indicating the percentage of allassessed applications (or some subset thereof) that resulted in fewerpotential vulnerabilities. In one example, with reference to FIG. 9, thebenchmark reporting process can include the following steps:

-   -   STEP 805: The application profile P is specified based, for        example, on the type of application and/or the business context.    -   STEP 710: The application is analyzed using a consistent,        repeatable process of determining, building and executing        appropriate tests as described above.    -   STEP 815: A standardized analysis summary S is generated by the        reporting engine 230 that contains an overall security score and        other security metrics.    -   STEP 905: The assessment results database 155 is queried using        the specified application profile(s). In some embodiments, a        first query can be executed looking for exact or very close        matches to the profiles. For example, if the application profile        is “customer-facing financial services web application written        in java” and the database contains a sufficient number of        assessment for a meaningful peer benchmark to be compiled,        (e.g., n>5), the application results R are compared to the        anonymous results Y by, for example, placing the subject        application in a designated quartile or decile. If the number of        results is insufficient, the query parameters may be expanded to        include results from applications that have similar (but not        necessarily exact) profiles until a desired result set is        obtained.    -   STEP 910: The peer benchmark data B may be displayed in tabular        and/or graphical format (e.g., a histogram) showing, for        example, the count of similar applications that scored in each        quartile. Application profiles of the anonymous applications can        also be shown along with the summary report.        Secure Delivery of Assessment Data

The vulnerability assessment process consumes and produces data that isconsidered highly confidential by most organizations. For example, inputinto the analysis phase can include application source code, applicationbinaries and debug symbols, and/or environment data (URLs,usernames/passwords, site maps). Because of the sensitive nature of thisdata, and because they indicate potentially exploitable security flawsin the associated application, provision is desirably made to keep theanalysis results confidential. In instances in which the platform isoperated as a centralized, offsite service, the need to secure thissensitive information becomes even more crucial. In various embodiments,the DRM packager 250 and engine 255 provide the following capabilities:

-   -   A secure “container” file that contains the assessment data in a        structured and encrypted form that can only be produced and        consumed by the DRM technology employed by the platform 105.    -   An API or application that transforms structured data into a        secure container and specifies the access control rules for the        contents of the secure container.    -   Secure container content access to a known/trusted application        when the access control rules are satisfied (typically specified        by the presence of a DRM license bound to the user and client        hardware).    -   An access token that provides access granting data (e.g., time,        machine hardware id, username, IP address, license id, etc.) to        allow access to structured data within the secure containers.

Using the DRM engine 255, steps may be taken to protect the initial dataprovided as input to the assessment process as well as the analysisresults. Once the submission data has been packaged into a securecontainer, access is granted to the trusted analysis application for theduration of the analysis. Analysis results can then be packaged into asecure container for remote viewing. A trusted secure viewer application(in conjunction with the DRM Client engine and access token) ensuresthat the analysis results are viewed by authorized users and preventsunauthorized copying via printer, cut/paste, print screen, or file copy.

Referring to FIG. 10, the following steps provide the secure receipt andanalysis of application source files and assessment data to and withinthe platform:

-   -   STEP 805: Create a remote application profile P using the        application metadata provided by the user and/or identified from        the application itself.    -   STEP 1005: Identify the input data D to the application        analysis, either manually by a user or automatically by the        analysis engine (e.g., a list of binary files, a list of source        code files, etc.)    -   STEP 1010: Place the submission data D in a secure container        using the DRM packager 250.    -   STEP 1015: Submit the secure container to the platform for        analysis as described above.    -   STEP 1020: Using the DRM engine 255, issue a limited-use DRM        license to the analysis engine to allow access to the analysis        input data.    -   STEP 710: The analysis engine 125 performs the prescribed        analyses using the DRM engine 255 and issued license to access        input data, and the output is stored in a secure database.

Referring to FIG. 11, once the analysis data is stored in the database,it can then be packaged and transmitted using similar DRM techniques andthe following steps:

-   -   STEP 1105: A user selects an application for which he wishes to        view the analysis results R from a remote site.    -   STEP 1110: The analysis results R are placed in a secure        container using the DRM packager 250 for viewing.    -   STEP 1115: The secure container is downloaded to a local machine        from the platform for viewing by the user.    -   STEP 1020: A limited-use license is granted to the local machine        to allow viewing of analysis results contained in the secure        container. The license limits use to the target machine, the        user, or in some embodiments, a combination of the two.    -   STEP 1120: The secure viewer displays the analysis results from        the secure container. The data is persistently protected and        operations like cut/paste/screen dump are disabled.

In some implementations, security analysis and vulnerability testingresults may be “packaged” or “bound to” the actual software itdescribes. In some cases, the software may be a commercially-availableproduct delivered via traditional methods such as CD-ROM or download,whereas in other cases the software may be a website or collection ofwebsites that provide the software and/or services over the Internet,commonly referred to as software as a service, or “SaaS”. In still othercases, software may refer to a collective of otherwise unrelatedapplications and services available over the internet, each performingseparate functions for one or more enterprises, (i.e., “cloud”computing). By linking the report to the software itself, downstreamusers of the software can access information about the software, makeinformed decisions about implementation of the software, and analyze thesecurity risk across an entire system by accessing all (or most) of thereports associated with the executables running on the system andsummarizing the risks identified in the reports.

Numerous techniques may be used for binding the report to and/orassociating the report with the executable. In some implementations, forexample, the binding can be “weak” in that the executable name andversion number are listed in the report and referenced either manuallyor automatically. If the report information is accessedprogrammatically, an executable a query can be submitted to a databasestoring a collection of software security reports and the desired reportretrieved. The database may be private (e.g., behind a firewall andaccessible only to authorized users or employees) or public, and madeavailable via the Internet to the general population for query andreview.

In other instances, the report may be “loosely” bound to the software bycomputing a cryptographically secure hash of the software and includingthe hash in the body, metadata or header of the report. In such cases,users of the software are provided with a hash program that computes therequired hash and submits the hash as a lookup key to a database ofreports. In this instance, the reports remain somewhat “decoupled” fromthe software as there may be many report providers and the reports maybe updated over time without needing to redistribute the software whichis desirable given the ever-changing threat landscape.

In another implementation, a “strong” binding between the software andits vulnerability report uses a URL as a unique reference address of thereport or, in some cases, the report is embedded alongside softwarebinaries in environments that support application packages. While not asflexible as the weak or loose techniques described above, no lookup isneeded and the report can “travel” with the software. For environmentsthat support application packages (WAR, EAR, JAR, Mac OS X app packages)the report is a file alongside the manifest in the bundle.

The vulnerability reports can be expressed in an XML format so thatautomated processes can query the report based on predetermined tags andfind the information needed to make security decisions regarding theexecutable. The report may be cryptographically signed by the reportprovider so that tampering with the report contents can bedetected—particularly important when the report is embedded in thebinary or included in an application package. An example of XML that maybe used to generate a report (or a portion of a report) is provided inthe table below:

<?xml version=“1.0” encoding=“ISO-8859-1” ?> - <detailedreportxmlns=“http://www.veracode.com/schema/reports/export”report_format_version=“1.1” app_name=“Sample Application” version=“1.0”platform=“Java” generation_date=“2009-09-17 18:30:34 UTC”> -<static-analysis> - <modules> <module name=“sample.war”compiler=“JAVAC_6” os=“Java J2SE 6” architecture=“JVM” score=“58”numflawssev1=“0” numflawssev2=“14” numflawssev3=“258” numflawssev4=“7”numflawssev5=“0” /> </modules> </static-analysis> - <dynamic-analysis> -<modules> <module name=“dynamic_analysis” compiler=“” os=“”architecture=“” score=“98” numflawssev1=“0” numflawssev2=“2”numflawssev3=“2” numflawssev4=“0” numflawssev5=“0” /> </modules></dynamic-analysis> <severity level=“5” /> - <severity level=“4”> -<category categoryid=“19” categoryname=“SQL Injection”pcirelated=“true”> - <desc> <para text=“SQL injection vulnerabilitiesoccur when data enters an application from an untrusted source and isused to dynamically construct a SQL query. This allows an attacker tomanipulate database queries in order to access, modify, or deletearbitrary data. Depending on the platform, database type, andconfiguration, it may also be possible to execute administrativeoperations on the database, access the filesystem, or execute arbitrarysystem commands. SQL injection attacks can also be used to subvertauthentication and authorization schemes, which would enable an attackerto gain privileged access to restricted portions of the application.” /></desc> - <recommendations> - <para text=“Several techniques can be usedto prevent SQL injection attacks. These techniques complement each otherand address security at different points in the application. Usingmultiple techniques provides defense-in-depth and minimizes thelikelihood of a SQL injection vulnerability.”> <bulletitem text=“Useparameterized prepared statements rather than dynamically constructingSQL queries. This will prevent the database from interpreting thecontents of bind variables as part of the query and is the mosteffective defense against SQL injection.” /> <bulletitem text=“Validateuser-supplied input using positive filters (white lists) to ensure thatit conforms to the expected format, using centralized data validationroutines when possible.” /> <bulletitem text=“Normalize alluser-supplied data before applying filters or regular expressions, orsubmitting the data to a database. This means that all URL-encoded(%xx), HTML-encoded (&#xx;), or other encoding schemes should be reducedto the internal character representation expected by the application.This prevents attackers from using alternate encoding schemes to bypassfilters.” /> <bulletitem text=“When using database abstraction librariessuch as Hibernate, do not assume that all methods exposed by the APIwill automatically prevent SQL injection attacks. Most libraries containmethods that pass arbitrary queries to the database in an unsafemanner.” /> </para> </recommendations> - <cwe cweid=“89”cwename=“Failure to Preserve SQL Query Structure (‘SQL Injection’)”pcirelated=“true”> - <description> <text text=“This database querycontains a SQL injection flaw. The function call constructs a dynamicSQL query using a variable derived from user-supplied input. An attackercould exploit this flaw to execute arbitrary SQL queries against thedatabase.” /> </description> - <staticflaws> - <flaw issueid=“83”module=“sample.war” severity=“4” type=“Failure to Preserve SQL QueryStructure (‘SQL Injection’)” description=“This database query contains aSQL injection flaw. The call to java.sql.Statement.executeQuery( )constructs a dynamic SQL query using a variable derived fromuser-supplied input. An attacker could exploit this flaw to executearbitrary SQL queries against the database. Avoid dynamicallyconstructing SQL queries. Instead, use parameterized prepared statementsto prevent the database from interpreting the contents of bind variablesas part of the query. Always validate user-supplied input to ensure thatit conforms to the expected format, using centralized data validationroutines when possible. References: CWE(http://cwe.mitre.org/data/definitions/89.html) OWASP(http://www.owasp.org/index.php/SQL_injection)” note=“” cweid=“89”remediationeffort=“3” exploitLevel=“0” sourcefile=“sample1.java”line=“213” sourcefilepath=“org/sample/utils”> - <mitigations><mitigation action=“Mitigated by Design” description=“The tainted datain this case comes from locked down database system tables.” user=“DemoUser” date=“2009-09- 04 14:12:34 UTC” /> <mitigation action=“MitigationAccepted” description=“This makes sense.” user=“Demo User”date=“2009-09-04 14:12:53 UTC” /> </mitigations> -<exploitability_adjustments> - <exploitability_adjustmentscore_adjustment=“−1”> <note>The source of the tainted data in this webapplication flaw is not a web request.</note></exploitability_adjustment> </exploitability_adjustments> </flaw> -<flaw issueid=“151” module=“sample.war” severity=“4” type=“Failure toPreserve SQL Query Structure (‘SQL Injection’)” description=“Thisdatabase query contains a SQL injection flaw. The call tojava.sql.Statement.executeUpdate( ) constructs a dynamic SQL query usinga variable derived from user-supplied input. An attacker could exploitthis flaw to execute arbitrary SQL queries against the database. Avoiddynamically constructing SQL queries. Instead, use parameterizedprepared statements to prevent the database from interpreting thecontents of bind variables as part of the query. Always validateuser-supplied input to ensure that it conforms to the expected format,using centralized data validation routines when possible. References:CWE (http://cwe.mitre.org/data/definitions/89.html) OWASP(http://www.owasp.org/index.php/SQL_injection)” note=“” cweid=“89”remediationeffort=“3” exploitLevel=“0” sourcefile=“sample1.java”line=“220” sourcefilepath=“org/sample/utils”> -<exploitability_adjustments> - <exploitability_adjustmentscore_adjustment=“−1”> <note>The source of the tainted data in this webapplication flaw is not a web request.</note></exploitability_adjustment> </exploitability_adjustments> </flaw>

One example of an automated process that references a boundvulnerability report may include a whitelisting agent operating assoftware. The software agent may execute on a server or client,including hand-held devices, smart phones, PDAs, and the like.Procedurally, the agent computes the hash value for the executable forwhich it is attempting to validate and sends the hash to its whitelistdatabase. If the hash is in the whitelist, the executable is permittedto execute (or be installed, copied, transferred or otherwise used).Conventional whitelisting databases only consider software provenancewhen making a binary decision whether to allow the software toexecute—if the provenance is known it runs, if not, the software is notexecuted. In contrast, the whitelist agent described herein takesadvantage the software security report to make a more informed decisionbased on numerous data points. For example, an overall software qualityrating or the number and type of known security defects may affect thedecision whether to execute the software or not, or under whatconditions the software may be executed.

For example, an organization may have a policy stating that a webapplication on the external network cannot have any cross-site scripting(XSS) vulnerabilities yet software running on the internal network mayallow XSS vulnerabilities. The policies used by the whitelisting agentsrunning externally can refer to the software security report for a countof XSS defects, and if the count is non-zero, restrict the execution ofthe software.

In other cases, the security report may be used to verify that properchange and release processes were followed for new versions of thesoftware. In a controlled change and release process, decision gates maybe used to control a release of the software into a productionenvironment or for use as a gold disk for reproduction. With the reportbound to an executable, an automated scanning application mayinvestigate a production environment and verify the efficacy of thechange and release process by ensuring that all deployed binaries have arecent report and a valid security rating.

In another example in which software is distributed through a centralrepository (e.g., SourceForge, iTunes App Store, BlackBerry AppWorld,Android Marketplace, etc.) bound security reports offer a higherassurance level to the consumer because the application has been ratedfor security and not tampered with prior to downloading. In someinstances the reports may be made available through the same centralrepository. In certain instances, the software vendor may make oneversion of the application available for free or a reduced price, butanother version that includes the security report (or access to it)available at a higher price, as some customers may appreciate the addedvalue and security that access to the report and data provides.

The bound security report may also be used in conjunction with anapplication installation process for desktop or server applications.Where today operating systems such as Windows Vista alert the user if anunsigned application is to be installed, a future system might detectthe presence of a ratings report and display it, or alert to the absenceof a ratings report. Similarly, bound security reports may be used tostrengthen browser security policies by providing more information aboutthe applet to be run.

The invention can be embodied in other specific forms without departingfrom the spirit or essential characteristics thereof. The foregoingembodiments are therefore to be considered in all respects illustrativerather than limiting on the invention described herein.

What is claimed is:
 1. A computer-implemented method for providingaccess to security data related to a software application, the methodcomprising: creating a programmatic association between the softwareapplication and results of one or more security analysis tests performedagainst the software application wherein the results comprise referencesto flaws identified in source code of the software application; storingthe results for subsequent electronic access on a data storage servercomprising a security-threat database; providing access to the softwareapplication and instructions to access limited portions of the resultsstored in a central database using a unique key associated with an ownerof the software application and the software application such that theresults, including the source code, may be reviewed on demand by a userauthenticated to use the unique key.
 2. The method of claim 1 whereinthe software application comprises executable object code distributedover a network.
 3. The method of claim 2 wherein the results aredistributed with the executable object code.
 4. The method of claim 3wherein the software application comprises an application package andthe results are included in the application package.
 5. The method ofclaim 1 wherein the software application comprises a web-based serviceaccessible over a network.
 6. The method of claim 1 wherein the softwareapplication comprises a collection of unrelated computing functionsavailable over the Internet.
 7. The method of claim 1 further comprisingdisplaying the limited portion of the results to the user in response toa query submitted to the database.
 8. The method of claim 1 furthercomprising transmitting the limited portion of the results to the userin response to a query submitted to the database.
 9. The method of claim8 further comprising encrypting portions of the results prior totransmission.
 10. The method of claim 1 further comprising: (i)computing a hash of at least a portion of the software application; (ii)including the hash with a report comprising the results; and (iii)receiving a request from the user to view the results, the requestincluding the hash such that the hash is used to identify and access theresults.
 11. The method of claim 1 wherein the instructions to access areport comprising the results comprise a URL directing the user to thereport.
 12. The method of claim 1 wherein a report comprising theresults comprises an XML document, the XML document further comprisingpredefined tags.
 13. A system for providing access to security datarelated to a plurality of software applications, the system comprising:at least one testing engine for performing a plurality of vulnerabilitytests on the software applications and associating results of the testswith the respective software application wherein the results comprisereferences to source code of the software application; a database forstoring the results; and a communications server for receiving a requestfrom a user of one of the software applications, the request including aunique key associated with an owner of the software application and theuser, to access the results associated with the software application,and, based on the received request, provide the results, including thesource code, associated with the software application to the userauthenticated to use the unique key.
 14. The system of claim 13 whereinthe communications server further displays the results to the users. 15.The system of claim 13 wherein the software application comprisesexecutable object code distributed over a network.
 16. The system ofclaim 13 wherein the software application comprises an applicationpackage and the results are included in the application package.
 17. Thesystem of claim 13 wherein the software application comprises aweb-based service accessible over a network.
 18. The system of claim 13wherein the software application comprises a collection of unrelatedcomputing functions available over the Internet.
 19. The system of claim13 wherein the testing engine is further configured to compute a hash ofat least a portion of the software application, and the communicationsserver is further configured to include the hash with a reportcomprising the results and wherein the request includes the hash suchthat the hash is used to identify and access the results.